home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.std.c
- Path: blackbush.xlink.net!slsv6bt!slsv6bt!kanze
- From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
- Subject: Re: Undefined result vs. int's holding undefined values.
- In-Reply-To: Daniel Wood's message of 8 Jan 1996 22:00:32 GMT
- Message-ID: <KANZE.96Jan9115946@slsvewt.lts.sel.alcatel.de>
- Sender: news@lts.sel.alcatel.de
- Organization: SEL
- References: <4ck70b$rd7@news.informix.com> <4ckms5$rd7@news.informix.com>
- <4cmg0s$1mb@der.twinsun.com> <oZA8wQ9ytpjN084yn@csn.net>
- <4cs460$d6e@news.informix.com>
- Date: 09 Jan 1996 10:59:45 GMT
-
- In article <4cs460$d6e@news.informix.com> Daniel Wood
- <dwood@informix.com> writes:
-
- |> I totally understand what you are doing in the above but this would have to
- |> be the ultimate in a cheap out for a vendor. SCO could claim that before
- |> ever looking at a test case containing a suspected compiler bug that every
- |> arithmetic calculation would have to first have a test similar to the above
- |> to protect against overflow/underflow. Does an appropriate "SAFE TEST" exist
- |> for multiple.
-
- Yes, but you have to do the actual operations using the absolute
- values, and then generate the sign yourself. Basically, for positive
- values, x * y will overflow if and only if x > y / INT_MAX. (You must
- use positive values because division with negative values is not well
- defined, and if the result will be negative, the test must use
- -INT_MIN instead of INT_MAX.)
-
- |> Has anyone actually seen a real production program where every
- |> calculation was protected against overflow/underflow.
-
- Yes. In the late 80's I worked on a Basic interpreter where all
- overflows generated a run-time exception. Given the overhead of the
- interpreter, and the type of applications that were being written in
- Basic, the overhead for checking was perfectly acceptable. Although
- the code was written before ANSI introduced the concept of `undefined
- behavior', it was written such that an integer overflow could never
- occur, even in results that would later be thrown out (because of
- error detection). It's not particularly hard; all that is needed is
- 1) that the requirements require it, and 2) that the performance
- penalty is acceptable.
-
- [...]
- |> Do any machines exist which actually explode when you add two number together
- |> such that the result would exceed MAXINT? :-) Get pratical!
-
- Explode, perhaps not. But a core dump would be an appropriate
- behavior. Most programs don't check for overflow on the grounds that
- garbage in/garbage out is an acceptable modus operandi. Practically,
- overflow cannot occur for reasonable values of input, and they
- consider undefined behavior acceptable for unreasonable user input
- (given that in reality, we know that the undefined behavior won't
- actually cause loss of life or property). In such cases, overflow
- represents a failure in the model; it would be nice to have the
- program fail if the model fails, rather than simply give wrong
- results.
-
- |> I am particularly interested in the answer to my "safe multiply" question
- |> above. It would be quite funny to find that there is actually no way to
- |> create, in a practical way, a safe c program that used multiple if the
- |> standard was followed to the letter of the law. I have thought of a way
- |> but it would be alot more involved then the sum_overflow() check above.
-
- It is somewhat more complicated than the above.
-
- In most cases, the correct solution is *not* to test each individual
- operations, but to validate all input values for `reasonableness', and
- then prove that overflow cannot occur for reasonable values of input.
- --
- James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
- GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
- Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
- -- A la recherche d'une activitΘ dans une region francophone
-
-